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Abstract 


We propose an approach to formally verify Plural specifications based on access permissions 
and typestates, by model-checking automatically generated abstract state-machines. Our 
exhaustive approach captures all the possible behaviors of abstract concurrent programs 
implementing the specification. We describe the formal methodology employed by our tech- 
nique and provide an example as proof of concept for the state-machine construction rules. 
The implementation of a fully automated algorithm to generate and verify models, currently 
underway, provides model checking support for the Plural tool, which currently supports 
only program verification via data flow analysis (DFA). 


1 Introduction 

Multi-core processor platforms are poised to become massively parallel within the next few 
years. To take advantage of this new technology, computer scientists are working on the 
development of programming languages and programming paradigms that exploit the par- 
allel computing power provided by the new hardware. For example, the /Eminium research 
project [19], which succeeds Plural [15], is developing a platform that enables programmers 
to write concurrent-by-default programs, and is prone to support massive parallelism. The 
Plural language uses Java syntax and is inspired by purely functional programming lan- 
guages in which programmers express not a sequence of side-effect operations but rather 
how a result should be built functionally from an input. The order of the execution does 
not matter as long as the dependencies within the program are respected. The Plural 
language proposes a new way of structuring object oriented programming based on code 
dependencies and data-flow alone. Plural programmers provide data dependencies thus en- 
abling Plural runtime system to parallelize the program. Dependencies are written as access 
permissions [3, 6] that express logical dependencies on concurrent execution runs. Access 
permissions are abstractions describing how objects are accessed. For instance, a Unique 
access permission describes the case when a sole reference to a particular object exists, and a 
Shared access permission models the case when an object is accessed by multiple references. 
Access permissions are inspired by Girard’s Linear Logic [12]. Method access permissions 
specifications are produced and consumed, in the spirit of Linear Logic. 

The /Eminium concurrent-by-default platform is still under development and efforts are 
in place to develop techniques to improve the analysis performed by its current implemen- 
tation. In particular, /Eminium does not provide support for model checking. In this paper, 
we propose a new formal approach that enables reachability analysis of Plural specifications. 
First, we translate Plural specifications into abstract state-machines that capture all pos- 
sible behaviors allowed by the specification. Then, we use a symbolic model checker based 
on edged-valued decision diagrams (EVMDD) [16] to verify that specifications satisfy a set 
of basic integrity properties such as absence of deadlock, absence of unreachable code, and 
correct use of access permissions. Additionally, the ability to express custom temporal logic 
properties for concurrent programs gives the analysis the freedom to perform verification 
tasks tailored to each application. Finally, we use a Petri net inspired semantics to represent 
access permission transformations. In contrast to Plural, the focus of our analysis is not 
on program verification (concrete code implementing a specification) but on verifying the 
specification itself. 

The rest of this document is organized as follows. The remaining part of this section 
presents related work. Section 2 introduces the specification language used by Plural (access 
permissions) and its extension used by the Plural tool (access permissions and typestates). 
Section 3 presents the state-machine model used for verifying Plural specifications. Section 
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4 describes the algorithm that translates Plural specifications into the state machine model. 
Section 5 presents the Petri-Nets based approach to formally verifying Plural specifications, 
together with a case study taken from a commercial data base application. 

Related Work: In previous work [8], we used the jmle tool [13] for writing JML specifi- 

cations [14] of an electronic purse application written in the Java Card dialect of Java. JML 
is a behavioral interface specification language for Java, which means that the only correct 
implementation of a JML class specification is a Java class with the specified behavior. JML 
method specifications are written with the aid of the keywords requires, modifies and en- 
sures, which respectively give the precondition, the frame (what locations may change from 
the pre- to the post-state) and the postcondition. JML provides support for the declaration 
and use of specification-only variables (e.g., using the model construct). Typestates can be 
regarded as JML abstract variables and so JML tools can be used to simulate typestate ver- 
ification of specifications. However, JML does not provide support to the reasoning about 
access permissions. JML’s support for concurrency is rather limited. The work presented 
here is more complex than the work presented in [8] , as it involves reasoning on concurrency 
properties of a system. 

The Plural group has conducted different case studies on the use of typestates to verify 
Java I/O stream libraries [3], Java iterator libraries [4], and Java database libraries [5]. 
The main goal of these case studies is to show that Plural can effectively be used to check 
violations of APIs protocols. The work presented in this document focuses on verifying 
Plural specifications in isolation regardless of the program source code, instead. 

Validating temporal safety properties of software has been proposed in [2] and applied to 
Windows NT drivers. The technique, based on predicate abstraction, is implemented in the 
SLAM toolkit. It automatically creates abstractions of C code using iterative refinement and 
has been used to verify correct locking behavior. In [10], the Vault programming language 
is used to describe resource management protocols that the compiler can statically enforce. 
Protocols can specify that certain operations must be performed in a certain order and that 
certain operations must be performed before accessing a given data object. The technique 
has been used on the interface between the Windows kernel and its device drivers. 

Finally, we have previously employed symbolic model checking for analyzing languages 
and software. In [11], we have checked the locking mechanism of the Linux Virtual File 
System (VFS) by extracting abstract models from the Linux kernel. In [18], we have vali- 
dated the correctness of syntactic macro-definitions proposed for the plan execution language 
PLEXIL, and in [17] we have studied the semantics of temporal properties specified in the 
planning language ANMLite. 


2 Specifications for Plural Programs 

The Plural language is based on access permissions and Plural combines these with type- 
states. Typestates define protocols on finite state machines [20]. They can be used as 
abstractions to reason about objects and programs [1]. They are abstract definitions on the 
capability of a method to access a particular state [3,6]. Access permissions are inspired 
by Girard’s Linear Logic [12], hence, they can be used, produced and consumed. Access 
permissions are used to keep track of the various references to a particular object, and 
to check the types of accesses these references have. Accesses can be reading or writing 
(modifying). Plural provides support to five types of access permissions, namely, Unique, 
Share, Immutable, Full, and Pure. Figure 1 presents a taxonomy of how different access 
permissions can coexist. For example, Full access to a referenced object allows the existence 
of any other reference with Pure access to the same referenced object. 
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Figure 1. Simultaneous access permissions taxonomy [3] 


• Unique(x). It guarantees that reference x is the sole reference to the referenced 
object. No other reference exists, so x has exclusive reading and modifying (writing) 
access to the object. 

• Full(x). It provides reference x with reading and modifying access to the referenced 
object. Additionally, it allows other references to the object (called aliases) to exist 
and to read from it, but not to modify it. 

• Share (x). Its definition is similar to the definition of Full(x), except that other 
references to the object can further modify it. 

• Pure(x). It provides reference x with read-only access to the referenced object. It 
further allows the existence of other references to the same object with read-only access 
or read-and-modify access. 

• Immutable (x). It provides x and any other existing reference to the same refer- 
enced object with non-modifying access (read-only) to the referenced object. An 
Immutable permission guarantees that all other existing references to the referenced 
object are also immutable permissions. 

The Linear Logic formula P — o Q is modeled as the specification @Perm(requires=“P”, 
ensures=“Q”) of the Plural language. The semantics of the operator (g> of Linear Logic, 
which denotes simultaneous occurrence of resources, is captured by the operator P and 
Q can be a specification such as Unique(x) in A * Full(y) in B, which requires (ensures) 
that reference “x” has Unique permission on its referenced object, which should be in state 
A, and simultaneously requires (ensures) that “y” has Full permission on its referenced 
object, which should be in state B. The semantics of the additive conjunction operator “&” 
of Linear Logic, which represents the alternate occurrence of resources, is captured by the 
use of a @ Cases specification, the decision of which is made according to a required resource 
in one of its @Perm specifications. The additive disjunction operator ® of Linear Logic is 
modeled by the use of a @ Cases specification, the decision of which is made according to an 
ensured resource by one of its @Perm specifications. Typestates are declared with the aid 
of the @ClassStates clause. Method specifications are written with the aid of the @Perm 
clause, composed of a “requires” part, describing the conditions required by a method to be 
executed, and an “ensures” part, describing the conditions that hold after method execution. 
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Additionally, the clause @ Cases allows the annotation of several @Perm specifications for 
a method. The constructor of the class ProducerConsumer creates a Unique object that 
is initially in state Empty. A @TrueIndicates specification defines the state generated 
by a method when it returns true. The resources are stored in a container of bounded 
size. Therefore, when the container becomes full, producing is no longer allowed before 
consuming at least one resource. Consuming is obviously not permitted when the container 
is empty. The following basic producer/consumer example, with one class, one constructor, 
two read-only methods, isEmpty() and isFilled(), and two read/write methods, produce() 
and consume(), illustrates an example of a Plural specified program. 


@ClassStates({ 

@State(name = "Empty") , 

@State(name = "Partial") , 

@State(name = "Filled") 

}) 

class ProducerConsumer { 

@Perm( ensures = " Unique ( this ) in Empty"); 
ProducerConsumer ( ) { ... } 

@Pure 

@TrueIndicates ( " Empty " ) 
bool isEmpty () { ... } 


@Pure 

@TrueIndi cates ("Filled") 
bool isFilledQ { ... } 


@Cases ( { 

@Perm( requires — 
@Perm( requires = 
@Perm( requires — 
}) 

void produce () { 


"Full (this) 
" Full ( this ) 
"Full (this) 

... > 


in Empty " , 
in Partial", 
in Partial", 


ensures 

ensures 

ensures 


Full ( this ) 
Full ( this ) 
Full ( this ) 


in Partial"), 
in Partial"), 
in Filled") 


@Cases ( { 

@Perm( requires = "Full (this) 
@Perm( requires — "Full (this) 
@Perm( requires = "Full (this) 
}) 

void consume () { ... } 


in P art i al " , 
in Partial", 
in Filled", 


ensures 

ensures 

ensures 


Full(this) in Empty") , 
Full(this) in Partial") , 
Full(this) in Partial") 


3 Abstract Models of Plural Specifications 

Our first approach to the verification of Plural specifications relies on an algorithm that 
extracts an abstract state-machine representation of the collective dynamic behaviors of the 
object references described in the specification. This section introduces the abstract state- 
machine model, and Section 4 presents the algorithm that translates Plural specifications to 
the abstract state-machine representation. The main difference between our approach and 
the line of research pursued by the Plural group in [3,5] is that, while using the same input 
language, we model and verify the specification alone and not programs (code analysis). 
Our abstract models are not concerned with the body of methods, but only with their 
specification: preconditions, postconditions, invariant conditions, and access permissions. 
Also by contrast, our technique is able to analyze the specification for any possible concurrent 
execution of programs implementing it, while the Data Flow Analysis (DFA) technique in 
Plural is designed to study one program at a time. 

A Plural specification comprises a finite set of class declarations C = {Ci, . . . , C c }. 
Every class Ci contains a set of typestate declarations, TSi = {tj , . . . , }, where h t is 

the number of typestates for class C*, for 1 < i < c. A typestate [20] might declare a 
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class-state invariant that relates the typestate with (Java) code. For each class declaration 
C'i , 1 < i < c, we create a finite number of instances of references to objects of that type: 
TZi = {rf, rj, . . . ,rj, . . . ,rf}. The parameter K is the only attribute of our model that is 
determined a priori. A meta-argument is necessary to support the decision to bound K to a 
predetermined value. We informally argue that K can be set to the number of simultaneous 
distinct access permissions to the same object, which is 5. The choice of parameter can be 
validated formally by extending the analysis to K = 6 (i.e. , by allowing multiple accesses 
of the same type) and showing that the extended model does not introduce any additional 
“relevant” behavior of r° in the model. 

We assume a default abstract representation of the operating environment. In a generic 
reference ( Xi,Oi ) to an object of class C), o t is the object uniquely described by its physical 
memory address, and X{ is the name of the alias to the physical object. We reserve rf to 
the generic reference (this,Oi). The abstraction represents the congruence relation over the 
equality with Oj. From the point of view of analyzing the behavior of (this, o,) in terms 
of access permissions, the behavior of other objects, (■ Dh,Oh ) with h ^ i, is completely 
independent, since it does not affect Oi. Thus, all references to other physical locations can 
be captured with a single abstract state, for example J_ = (-, null) . 

3.1 The Basic Component 

The building block of the model generated by our tool is the state-machine of an object 
reference rj , which includes: 

(a) the program counter, pc j £ VCi = {pre,post} x ({T} U {M} , . . . M™'}), two per each 
method, where we include the constructors in the list of methods. We reserve the symbol 
J_ for undefined values (for multiple domains: typestates, access permissions, methods), 
throughout the paper. 

(b) the access permissions associated with rj : a field of enumerated type 

apj £ AV = {J_, Unique, Full, Pure, Immutable, Share}. 

Additionally, for each object Oi we store its typestate (which is shared by all references 

rf',0 < j < K) tsi £ TSi = {_L} U {tj, ,t^}, where J_ describes an “undefined” state of 

a reference, corresponding to its “pre-creation” state. A reference is created by two means: 
either by calling a constructor method of C) or by pointing it to object o.j after its creation 
(aliasing). As mentioned before, we use the same abstract state J_ to represent references 
that point to objects other than Oi as well as null references. 

An mapping of the variables representing rj to values in their domain is called a local 
state. The cross product of all local states is called a global state. 

3.2 State transition rules 

From each post-local-state (a local state with pcj = (post,-)) we allow a non-deterministic 
transition to any other pre-local-state. This covers all possible sequences of method calls, 
which is behaviorly equivalent to placing the reference (this, Oi) in any possible global con- 
text. The transitions from post-local-states to pre-local-states are guarded by expressions 
that capture several constraints: 

(i) the required typestate condition of the pre-local-state 

(ii) the access permission constraints determined by the splitting rules described in sub- 
section 3.3 
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Additionally, from each pre-local-state ( pre,m ) a reference can only transition to its 
matching post-local-state (post, m), capturing the completion of the call to method to. The 
transition is guarded by the postcondition associated with the method in the specification 
and reflects the change in typestate that may occur. 


3.3 Access Permissions Splitting Rules 

Influenced by Boyland’s work in [7], Plural performs fractional analysis of access permissions, 
hence, they can be split into several more relaxed permissions and then joined back to form 
more restrictive permissions. Figure 2 presents Plural splitting and joining rules, where at 
least one of x± and X 2 is x, and k\ + k 2 = k. For instance, a Unique access permission of 
weight k can be split in two k/2 Share access permissions. At the present stage of our work, 
we fully abstract away the notion of permission fractions, since traditional model checking 
techniques do not handle continuous variables. 

Splitting rules govern the way transitions from post-local-states to pre-local-states can 
be carried out. If the pre -local-state of a method requires a reference “x” to have Unique 
permission to an object “o”, but the current post-local-state ensures that two half Share 
permissions to the same object “o” exist, then the method (non-deterministically) might 
still be executed. 


Unique(;r, o, k) 
Unique(;r, o, k ) 
Full (ar, o, k) 
lmmutable(;r, o, k ) 
lmmutable(;r, o, k ) 



Full(xi, o, k\) ® Pure(x2, o, k 2 ) 

Share(x 1 , o, k\) (g> Share(:r 2 , o, k 2 ) 
lmmutable(xi, o, k±) ® Immutable^, o, k 2 ) 
Pure(a;i, o, k{) <g> Immutable^, o, k 2 ) 
lmmutable(xi, o, hi) ® Immutable^, o, k 2 ) 


Figure 2. Access permission splitting rules 


4 Translation Algorithm 

The translation algorithm builds the two components of a finite state machine: the set 
of potential global states S and the transition relation between states, R C S x S. The 
potential state space is simply the cross product of the local state spaces: 

c / K 

S = l[l{±,tl,...,t1'}xl[(VC l xAV) 

*= 1 V i=° 

The transition relation can be defined component-wise, for each reference rj (the local 
transition relations Rj), and the global transition relation is the asynchronous composition 
of the local transition relations. 

Below, define the rules to construct each Rj. There are two types of local transitions, 
corresponding to starting a method and ending a method. In the following, we use the 
standard notation for pairs of states ( from states and to states) in the transition relation: 
unprimed variables refer to the from- state and primed variables to the fo-state. 

The routines Start-Method and EndMet-hod build the transition relation expressions asso- 
ciated with starting and ending ending a method to by a reference rj , respectively. The input 
for these routines are the reference rj , the method to, the global context (represented by the 
global state s and the global typestate t), and two triplets. The triplets Crfj , tsjf , apo \ and 
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( r ii ; ts^ . o.p-[ j encode the requires (indexed io) and ensures (indexed i\) clauses from 
the method’s specification, namely the required and ensured typestate, reference, and ac- 
cess permission. The output of the routines are two Boolean expressions: guard and update. 
The guard formula must hold for the transition to be enabled, and the update formula en- 
codes the changes in the values of global states that occur by executing a transition. The 
semantics of this pair of expressions is: “if guard evaluates to true in the current state then 
the transition can be executed and the global state changes according to update .” 


We employ the following types: 
GlobalTypestate = TSi x 
LocalState 
GlobalState 
Reference 
Triple 


x TS C 
(PC, AccessPermission ) 

Array[l..c] of Array [0..K] of LocalState 
( ObjectTdx, Aliasldx ) 

(Reference , Typestate , AccessPermission) 


Algorithm 1 computes the guard and update expressions for the transition corresponding 
to starting a method 
StartMethod( 
s : GlobalState, 
t : GlobalTypestate, 
rj : Reference, 
m : Methodi, 

(( r i°’ ts io’ a Po) ’ ( r ii’ ts h’ a Pi)) : Triplex Triple 

) 

guard <- s[i\\j].ap ± _L A s[i\[j].pc = (post, •) A t[i 0 ] = ts^A 

Compatible (s[io\[jo\.ap, apo) A Compatible (s[ii][ji].ap,api) 
update <— s'[?'][j].pc = (pre, m) A ChangeP emission (s[io] [jo]> a Po) 

return guard => update 


Algorithm 2 computes the guard and update expressions for the transition corresponding 
to ending a method. 

EndMethod( 
s : GlobalState, 
t : GlobalTypestate, 
rj : Reference, 
m : Methodi, 

(( r io’ ts i 0 °’ a Po) - ( r ii 1 > ts ii 1 > a f J i)) : Triplex Triple 

) 

guard <— s[«] [j].pc = (pre, m) 

update <— t'[i{\ = tsf 1 A s'[ii][ji].ap = ap\ A s'[t][j].pc = (post,m)A 

ChangePermission (s[?'i][ji].ap, api) 
return guard =$■ update 


In the special case when m is a constructor, the guard for StartMethod is slightly different: 
the first predicate, s[i][j].ap 7^ _L, enforcing that the reference rj exists, is replaced by 
f[i] = T that enforces the exact opposite: the object Oi has not been already created. 
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Integral parts of the algorithms are two routines that require further explanation. The 
routine Compatible(ap x , ap y ) implements a Boolean function that gives a “true or false” 
answer to whether the access permissions ap x and ap y are “compatible”, more precisely if 
ap x can be downgraded or upgraded to ap y according to Section 4.1, Figure 3. The rou- 
tine ChangePermission(ap x , ap y ) builds the update formula corresponding to a compatible 
access permission transformation from ap x to ap y . 

The formal arguments supporting these two routines are described in more detail in the 
next subsection (4.1). Informally, they implement an abstraction of the access permission 
joining and splitting rules, without having to explicitly introduce the notion of fractional 
permissions. 


j Next AP Unique Full Share Immutable Pure _L j 
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this others 
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this others 
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this others 
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i 

T 
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Figure 3. Access Permission Transformations (downgrade/upgrade). 


4.1 Access Permission Compatibility and Transformation Rules 

Access permissions can be transformed into a series of more lax permissions or combined 
together to form a more restrictive permission (see Section 3.3 and Figure 2). Gaining or 
losing permissions includes “no change” (i.e., the modification does not have to be strict). 
Scenarios where both this and other references strictly gain rights (access permissions) 
at the same time are considered incompatible. Similarly, scenarios where both this and 
other references strictly lose rights at the same time are also considered incompatible. This 
roughly follows the principles of linear logic regarding the “preservation” of resources. There 
are two generic ways of access permission transformations: 

• Downgrade: this reference may give up (read/ write) rights and other references may 
gain rights. 

• Upgrade: this reference may acquire more rights and other references may lose rights. 

Figure 3 describes in an abstract way the implementation of the routines Compatible () 
and Chang ePermission () presented before. The directional arrows denote the nature of the 
transformations: j for downgrade, f for upgrade, <-> for no change, and x for disallowed. 
Furthermore, the second row of symbols details the read and write permission change for 





Figure 4. State transition diagram for the producer/consumer example 


reference this and the other references (“the rest of the world”). Therefore, a Full permis- 
sion is compatible with a Share permission. Full can be downgraded to Share if reference 
this gives up writing permissions that are gained by the other references. Our analysis has 
found a single case of incompatibility, between Share and Immutable permissions, so they 
cannot be transformed one from another. 

In the absence of a fully specified constructor, the default constructor can be treated as 
a special pair of triples: 


((_L, this, _L) , ( initial , this, Unique)) 

Similarly, for creating an alias (assigning a pointer to an existing object): 

((_L, this, _L) , (t[c], this, Pure)) 

Figure 4 illustrates the state transition diagram for the basic module of the example of 
the ProducerConsumer class in Section 2. The transition guards are not depicted for the 
sake of simplicity, as they can be quite elaborate formulae. 

4.2 Experimental Results 

We have generated the input for the evmdd_smc [16] model checker from the above specifi- 
cation. For K = 5, the model has 4,660, 153 states, built in 0.19 seconds on a MacBook. 
None of the reachable states is deadlocked and the typestate reachability graph is identical 
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to the one in Figure 4, meaning that the specification has no blatant errors. The source 
code of the model generator and the generated producer/consumer model can be found in 
the appendix and at http : / / www3 . uma . pt/ncatano/ aeminium/Home . html. Figure 5 shows 
the state space size and runtime for checking the generated model parameterized by K 
(maximum number of coexisting references to the same object). 


K 

# states 

time (sec.) 

K 

# states 

time (sec.) 

1 

387 

0.00 

6 

44,698,270 

0.33 

2 

4,474 

0.01 

7 

422,650,621 

0.52 

3 

47,301 

0.03 

8 

3,952,714,382 

0.74 

4 

476,422 

0.08 

10 

337,317,139,558 

1.32 

5 

4,660,153 

0.19 

15 

~ 2.09 x 10 16 

3.55 


Figure 5. Experimental results: scalability for producer/consumer model 


5 A Petri Net Inspired Semantics for Fractional Access 
Permissions 

The access permission transformations required by our model are based on an underlying 
concept of “collective management” of permissions among references to the same object. In- 
tuitively, rights (access permissions) are viewed as resources (e.g., tokens) that are available 
globally. None, a portion of, or all resources can be used at a moment in time. Each object 
has its own share of resources, represented as a fraction or set of tokens. For example, 
a constructor creates an object with exclusive rights (Unique permission), therefore the 
constructor has to request all the tokens for that object. The tokens are initially stored in 
a “bank”, implementing the collective management of permissions, accessible to all. Refer- 
ences take and give back tokens depending on access needs, but the total number of tokens 
for each object is preserved. Hence, a global invariant property is that no resources are 
created or lost for each individual object. 

We can illustrate this concept first with the more general framework of fractional per- 
missions, where fractional permissions add up to 1. Note however, that we use this as a 
starting analogy only. Our implementation uses the bounding assumption of maximum K 
co-existing references to translate this framework into a fully discrete model where we map 
fractions from the continuous interval [0, 1] to the set {0, 1, . . . , K + 1}. 

A key departure from the original framework is to separate access permissions into read 
and write and describe the rights of a reference rj as a pair of fractions: (/r) , fwj), with 
f r i , f wj € [0, 1], representing the fraction of the read (and write, respectively) permissions 
to object Oi owned by reference rj. There are three semantic classes for the values of a 
fraction /: / = 0 (no permission), 0 < / < 1 (partial/shared permission), or / = 1 
(exclusive rights). The preservation of access permissions is a global invariant, with frf 
and fwf are the unused fractions (still in the bank). 

K K 

frf + Y f r i = 1 A f w i + Y f w i = 1 

j = 0 3=0 

The possible combinations of values for fractions is listed in Figure 6. The meaningless 
combinations arise from the implicit subordination of read permissions to modifying (write) 
permissions: a reference with modifying permissions has to have reading permissions as well. 
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this 

semantic 

bank 

others 

frj = 

0 A fwj = 0 

null 

frf > 0 A fwf > 0 

any 

frj = 

0 A fwj > 0 

no meaning 

- 

- 

0 < frj < 1 A fwj = 0 

Immutable 

fwf = 1 

, /u{ = 0 : Immutable or Pure 

0 < frj < 1 A fwj = 0 

Pure 

fwf < 1 

V/ A J : fw\ > 0, Pure or Full 

0 < frj, fwj < 1 

Share 

0 < frf < 1 A 0 < fwf < 1 

Vi A 3 ■ 0 < frf fw\ < 1, Share 

0 < frf < 1 A fwj = 1 

Full 

0 < frf < 1 A fwf = 0 

Vi A j ■ fw[ = 0, Pure 

frj = 

1 a fwj = 0 

Immutable 

frf = 0 A fwf = 1 

Vi A 3 ■ fr\ = 0 A fw\ = 0, Null 

frj = 

1 a fwj = 0 

Immutable 

frf = 0 A fwf < 1 

Vi A j '■ f r \ = 0 A fwj > 0, no meaning 

M = 

1 A 0 < fwj < 1 

no meaning 

- 

- 

f r l — 

1 A fwj = 1 

Unique 

frf = 0 A fwf = 0 

< 

Ik 

s 

II 

O 

> 

iL 

ii 

o 

13 

C 


Figure 6. A fractional permission model 

Also note that the nature of others rights can be inferred from the value of this reference 
and the bank: f r \ = ^~ ( f r { + frf) and f w \ = 1 - ( f w { + fwf). This helps 

determine locally the evaluation of the quantified formulae in the definition of certain access 
permissions without having to consult the actual values of the other references. This has 
practical importance for model checking in particular, where event locality can impact the 
efficiency of the analysis. 

With our bounding assumption of a maximum number of K distinct aliases per object, 
we can implement a simple yet sound system of transformation rules inspired by the afore- 
mentioned Petri net semantics. We map the infinite range of fraction values, the dense 
interval [0,1], to the discrete domain {0,1 ,. . . ,I\ +1}, via the abstraction 

( 0, if / = 0 

N : [0, 1] — » {0, 1, . . . , AT + 1}, N(f)=\ x € {1, . . . , K}, if 0</<l 

{ K+ 1, if / = 1 

In this model, there is an initial number of K + 1 tokens for each object and each 
access right (read, write) available at the bank. Operations take and restore an integer 
number of tokens, either directly from the bank or from another reference with multiple 
tokens. An upgrade in read or write permission is equivalent to taking tokens from the bank 
and/or others, while a downgrade is equivalent to returning tokens to the bank. In terms 
of transformation rules, this approach corresponds to associating the + and — symbols in 
Figure 3 with Petri net arcs for taking tokens from and returning tokens to the common 
pile, respectively. 

We can define two functions for the required number of tokens needed for the next oper- 
ation, N r and N w . There are multiple ways to define this pair of functions, as there is still 
non-determinism in the abstraction from fractions to integer values. The definition below 
corresponds to the most conservative approach in which references request the minimum 
amount of resources required for their operation: 


|0, if a = i_ 

N r : AV — > {0, . . . , K + 1} , N r (a) = < 1, if a € {Full, Pure, Immutable, Share} 

I K + 1, if a = Unique 
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0, if a G {_L, Pure, Immutable} 

1, if a= Share 

K + 1, if a G {Unique, Full} 


N w : AV — ► {0, . . . , K + 1} , N w (a) = 


To complete our model, in addition to the field ap in the basic module, we introduce 
two more fields, tkr and tkw, to represent the number of tokens of each type (reading and 
writing) that each reference q = rj holds. Then, the difference in number of tokens 5 
described below dictates the access permission transformations (upgrade, downgrade) from 
the currently owned number of tokens to the target number needed by ap': 

S r (q, ap') = N r (ap ) — s[q].tkr G {—{K + 1), . . . , — 1, 0, 1, . . . , K + 1} 

S w (q,ap') = N w (ap') - s[q].tkw G {-(A' + 1), . . . , -1,0, 1, . . . , K + 1} 

A negative 5 means downgrade, while a positive one means upgrade. The deficit (or 
surplus) is taken from (or given back to) the bank when available, otherwise the deficit is 
taken from other references in post state, without violating the requirements of the references 
in pre state. 

We illustrate this new technique on the producer /consumer example presented in Section 
2. The methods isEmpty() and isFilled() require non-exclusive rights (Pure), therefore the 
guard for starting isEmpty() checks whether the reference has the one read token necessary 
or it needs to “borrow” it from the bank or others. This results in two distinct types of 
transitions for isEmpty( ): 

• If tkrf + tkr j > 1, corresponding to 6 r (q, Pure) > 0, then tkrjf = 1 A tkrf r = 
tkrf + tkr j — 1 

• If tkrf + tkr \ = 0 f\3h ^ j : pc / = (post, •) A tkr f > 1, corresponding to 5 r (q, Pure) < 
0, then tfcr}/ = 1 A tkr // = ffcr/ — 1 (one read token transferred from r/ to r\) 

Due to the existential quantifier in the guard of the second type of transition for isEmpty(), 
this results in K individual transitions of this type, one for each h ^ j. 

The methods consume () and produce () require non-exclusive read rights and exclusive 
write rights. The exclusive rights are translated into requiring that no other reference is 
writing, V/i ^ j : tkw / = 0. All write tokens are then collected by rj : tkwjr = K+lAtkwf / = 
0 A Wi j : tkw'jf = 0. The read rights requirements result in two subcases, similar to 
isEmpty() . 

This model construction can be further optimized, by requiring that all methods re- 
turn the tokens to the bank upon completion. This affects only the pre-to-post transitions: 
tkrjr = 0 A tkrf / = tkrf + tkrj. Therefore, all available tokens at any time can be found 
only at the bank, which eliminates the need to check the other K references. With this ob- 
servation, the K different transitions resulting from the existential quantifier are no longer 
needed. Besides brevity, this optimized model has the desired property of increased event 
locality (fewer dependencies between variables among different references), which dramati- 
cally improves the performance of the model checker. 
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5.1 The Model Generator 

A C program is used to generate the evmdd_smc models in the framework just described. 
The input parameters to this program are c, the number of distinct objects, and K, the 
number of distinct references for each object. The program constructs a model that contains 
three sections: variable declarations, variable initializations, and the transition relation. 

a) Abstract variable domains. 

As all variables in the model have to be discrete (more precisely of an integer interval 
type) we have to define the abstract domains for all such variables. The domain 
TSi = {_L} U {tj, . . . ,tj} are mapped to [0,/ij]. The domain of method identifiers 
{_L} U {Mj, . . . , Af" 1 ' } is mapped to [0,m,]. The domain of access permission types 
AV = {_L, Unique, Full, Pure, Immutable, Share} is mapped to [0,5]. For the 
variables referring to tokens, we use the domain [0, A" + 1]- For the {pre, post} type 
we use [0, 1]. 


Domain 

concrete 

abstract 

Typestates 

TS X 

{±}U{t},...,tf} 

[0.. 

■ ■hi] 

Method ids 

Mi 

{1}U {Ml,..., M^} 

[0.. 

■ ■ mi] 

Access permissions 

AT 

{_L, Unique, Full, Pure, Immutable, Share} 

[0. 

..5] 

Number of tokens 


[0...K+ 1] 

[0.. 

. . K + 1] 

Program counter 

VC 

{pre, post} 

[0.. 

..1] 


b) Variable declarations. 

For each object Oi, we declare two categories of variables. One category refers to the 
object proper and includes three variables: statei of type T Si, tkrf and tkwf of type 
[0, K + 1], The second category is for references to the object. For each of the K + 1 
references to Oj, we define five variables: pc j of type [0, 1], method { of type [0, m*], ap { 
of type [0, 5], tkr { and tkw j of type [0, K + 1]. 

Hence, we have c * (3 + 5 * ( K + 1)) variables in the model. 


Variable 

name 

type 

Typestate 

state ^ 

[ 0 .. 

hi] 

Read tokens in the bank 

tkrf 

[ 0 .. 

K + 1] 

Write tokens in the bank 

tkwf 

[ 0 .. 

K+ 1] 

Program counter of r} 

PC l 

[ 0 .. 

1] 

Method executed by r \ 

method \ 

[ 0 .. 

m.i] 

Access permission of r[ 

a P l 

[ 0 .. 

5] 

Number of read tokens of r\ 

tkr j 

[ 0 .. 

K + 1] 

Number of write tokens of r\ 

tkwf 

[ 0 .. 

K + 1] 


c) Variable initializations. 

For each object: statei = 1 A tkrf = K + 1 A tkwf = K + 1. 

For each reference: 0 < j < K: pc} = post, method { = _L, ap\ = _L, tkr { = tkw j = 0. 

d) Transition relation. 

Each transition has a guard expression (the enabling condition) and an update expres- 
sion (the transformation performed by executing the transition). Unprimed variables 
refer to values before the update (the “from” state), while primed variables refer to 
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values after the update (the “to” state). For each object o.; there is a set of transitions 
generated for each reference to the object r? (K + 1 sets). Similar to the translation 
algorithm in Section 4, guard and update expressions are generated from the requires 
and ensures clauses associated with the corresponding method in the specification. 
More precisely, the requires clause impacts the guard of starting a method, while the 
ensures clause impacts the update due to ending a method. 

Therefore, we can identify four categories of transitions in our model, described in 
detail below. 

1. Reference r? starts a constructor. 

The guard only enforces that the object has not been created yet: /\f =0 (ap? = -L). 

The update expression sets the program counter and method of r? and takes 
all K + 1 tokens of both types (read and write) from the bank: pc?/ = pre A 
method ?/ = constructor A ap?/ = Unique A tkrf / = 0 A tkwf/ = 0 A tkr?/ = 
K + 1 A tkw?/ = K + 1. 

2. Reference r? starts a method to/ . 

The guard contains four conjuncts. The first requires r? to exist (not undefined): 
ap ? ^ _L. The second requires it to be in a post state (not executing something 
else): pc? = post. If the specification of to/ also requires that some object Oh 
(NB: must commonly but not necessarily the same Oi ) to be in state t'f t , the third 
conjunct enforces that: stateh = t%. 

The fourth conjunct checks the availability of access permission tokens. As ex- 
plained in the definition of N r and N w , there may be 0, 1, or K + 1 tokens 
requested for read and/or write permissions associated with method to/. In gen- 
eral, if ir/ and tw / are the number of tokens needed to execute method to/, 
then the fourth conjunct is: tkrf > tr/ A tkwf > twf. Note that if fr/ = 0, 
the expression tkrf > tr / is always true, hence it can be ignored. The same 
observation holds for the case twf = 0. 

The update expression has two conjuncts. The first reflects the changes in the 
state of r ?: pc?/ = pre A method?/ = k A ap?/ = ap. The second reflects the 
changes in the distribution of tokens: tkr.j^ r = tkr.j^ — tr/ A tkw t / = tkw , — tw / 
A tkr?l = tkr? + tr / A tkw?/ = tkwf + tw /. 

3. Reference r? ends a method to/. 

The guard ensures that the reference is actually executing method to/: pc? = 
pre A method? = k. 

The update expression reflects the change in the state of r? : pc?/ = post, and 
returns all the access permission tokens held by r? back to the bank: tkrf / = 
tkrf + tr / A tkwf r = tkwf + tw / A tkr?/ = tkr? — tr / A tkw?/ = tkwf — tw\. 

If the specification of to/ also ensures that some object Oh (again, not necessarily 
the same Oi) is left in state t the second conjunct enforces that: stateh > = 

4. Reference r? is a newly created alias. 

The guard expression requires that the object exists, statei ^ _L, r? has not been 
previously created, ap? = _L, and enough read tokens exist for a pure access, 
tkrf > 1, which is the most conservative approach. 

The update expression is pc?/ = post A method?/ =1A ap?/ = Pure. 
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5.2 Properties of Interest 

Within this framework, we can define several categories of generic properties that can be 
checked on any specification. They can be automatically generated and provide useful 
insight. 

Sink states (Deadlock). The presence of states without successors (sink states) may have 
different root causes, including improper use of access permissions that block the progress of 
all threads, among which deadlock (due to mutual circular wait) is one particular undesired 
behavior. 

In the CTL temporal logic [9], it can be expressed as simply as: 

deadlock : ->E X(true) 

Once the state space is constructed, finding sink states is a very computationally inexpensive 
operation. 

Typestate adjacency graph. Often, when laying out a specification, the designer knows 
in advance the expected control flow through the typestates of a class. This can be captured 
(and even depicted graphically) by means of the adjacency graph of the typestates. For 
instance, in a generic database application similar to the one presented in Section 5.3, the 
nominal flow of a task would be a linear graph traversing the typestates: _L — » created — > 
ready — > completed — > destroyed. 

In CTL, the adjacency relation can be written VI < i < c, Vt-| ^t 2 £ TSp. 

adjacent i (ti,0) : statei = <1 A E X(statei = £ 2 ) 

Concurrency. Access permissions are abstractions used to represent how an object is 
used. These abstractions can be used for parallel execution of methods along with some 
other dependency information. The present Plural specification includes knowledge about 
access permissions but does not have explicit knowledge of other dependencies. Even with 
this partial knowledge only, we can infer certain facts about method execution order. For 
instance, we can find all the possible pairs of methods that can be executed in parallel and 
all the pairs of methods that can never be executed in parallel. 

In CTL, VI < i < c, 0 < ji ^ j -2 < K, Vrrii ^ m 2 € Mp. 

concurrent , (mi, m 2 ) : EF ( ' pc { 1 = (m\,pre) A pc { 2 = (m 2 ,pre)^J 

Note that due to the symmetry in the model, it is sufficient to consider = 0 and j-i = 1. 
An empty set of states satisfying property concurrenti (mi, m 2 ) indicates that methods mi 
and m 2 can never be executed in parallel, while a non empty set means the opposite. 

Correct use of access permission. A set of integrity checks can be performed to ensure 
that each access permission requirement attached to a method does not violate the intended 
semantics described in Section 2. This is theoretically enforced by the model construction 
presented in Section 5, therefore double-checking the construction would provide additional 
proof of correctness for the entire concept. Of the five access permissions, only violations 
of three have meaningful representations, as the remaining two (Pure and Share) do not 
impose restrictions on other coexisting references. Furthermore, the predicates for Full and 
Immutable are the same. 

In CTL, VI < i < c,Vm € Mi, VO < j\ ^ j 2 < K : 
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unique .access (m) : AG-i (pet 1 = ( m,pre ) A apf 2 ^ 
fulLor jimm .access (m) : AG^ ^pc^ 1 = ( m.,pre ) A pc^ 2 = (-,pre) A tfcud 2 > O^j 

5.3 Application 

We present a case study on a Plural specification taken from a real database application, 
that has been previously used in Plural experiments. We first present an actual flawed 
attempt to write the specification and show how model checking can help expose and then 
correct the errors. 


@R.efine ( { 

(©States (dim = "A 
(©States (dim — 

}) 

@ClassStates({ 
(©State (name — 
(©State ( name — 
(©State (name — 
(©State (name — 


value={" Created " , 
value={ "U.Data" , 


"Ready" , "Comlpleted 
P_Data" , "F_Data"}) , 


dat a ! = null " ) , 
dat a ! = null " ) , 
dat a ! = null " ) , 
dat a == null " ) , 


"B 


"Created" , inv =' 
" Ready " , inv =' 
"Completed" , inv =' 
"Destroyed" , inv =' 


(©State ( name 
(©State ( name 
(©State ( name 

}) 


"U.Data" , inv=" Unique (data)") , 
"F.Data" , inv=" Full (data)") , 
"P_Data", inv="Pure (data) ") 


public class mttsTask { 


private MttsTaskDataX data ; 

@Perm( ensures= " Unique ( this ) in Created") 
@Unique( ensures="U_Data" ) 
mttsT ask ( ) 

{ data=new MttsTaskDataX ( ) ; } 

©Fulls ( { 

(©Full ( requires=" Created " , ensures=" Ready " ) , 
(©Full ( requires = " F_Dat a " , ensures=" F_Dat a " ) } ) 
public void setData ( MttsTaskDataX data) 

{ ■■■ i 

@Pure( requires^" P_Dat a " , ensures=‘P_Data" ) 
public MttsTaskDataX getData () 

{ return data ; } 


©Full ( re quire s = " Ready ", ensure s = "Completed") 
public void execute () 

i . . . > 


©Full ( require s = " Complete" , ensures= " Destroyed " ) 
public void delete () 

{ data = null ; } 


Destroyed"}) , 


Figure 7. Specification of mttsTask. java with errors. 


The class mttsTask models a generic processing task in the database system. The inter- 
nal information about the task is stored in a private member data of type mttsTaskDataX. 
The constructor of class mttsTask creates a Unique object that is initially in state Created. 
The method setData () requires this to have Full permission on its referenced object, which 
should be in state Created. Method executeO requires this to have Full permission and to 
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be in state Ready, and ensures that this will have Full permission on its referenced object, 
which will be in state Completed. The method delete () sets data to null and moves the 
task to the Destroyed typestate. 


@ClassStates({ 

@State(name = "Created" , 

@State(name = "Ready" , 

@State(name = "Completed" , 

@State(name = "Destroyed", 

}) 

public class mttsTask { 

private MttsTaskDataX data ; 

@Perm (ensures= "unique (this) in Created") 
mttsT ask ( ) 

{ data=new MttsTaskDataX ( ) ; } 

@Full ( requires=" Created " , ensures= "Ready") 

@Perm( requires = " #0 ! = null " ) 

public void setData ( MttsTaskDataX data) 

{ t his . data=data ; } 

@Pure( requires = " Ready " , esnures=" Ready " ) 
public MttsTaskDataX getDataQ 
{ return data ; } 

@Full ( r e q u i r e s = " Re ady " ,ensures= "Completed") 
public void execute () { } 

@Full ( requires=" Completed " , ensures= "Destroyed") 
public void delete () 

{ data=null ; } 


inv=" data ! =null " ) , 
inv=" data ! =null " ) , 
inv=" data ! =null " ) , 
inv=" data == null " ) , 


Figure 8. Corrected specification of mttsTask. java 


Note that the typestate hierarchy in this example has two dimensions (labeled A and 
B). Dimensions were not discussed in previous sections. They define a Cartesian product 
of possible states an object can have. Dimensions are modeled very straightforwardly by 
using two distinct variables (stateA and stateB), one for each dimension. The state-space 
for the typestates is simply the cross product of the two subdomains. In this example, the 
specification of the second dimension is trying to mimic the access permissions on the held 
data. The notation ‘ ‘#i’ ’ is used to refer to the I th argument of a method. In this case, 
the 0 th argument of setDataO is of type mttsTaskDataX. 

Finally, one other feature not covered so far are the invariants. In their most general 
form, they cannot be captured by our automated approach. However, in this instance, the 
invariants are simple equality checks on data. This is captured by a single boolean variable 
that represents whether data is null or not. 

As mentioned before, the specification in Figure 7 contains errors. However, the Plural 
tool does not generate any warning or error message. The first error is a simple syntax 
error in method delete (). The typestate Completed is misspelled as Complete. With this 
incorrect specification, the method delete!) cannot be called after the method execute!). 

The second is a semantic error. After the constructor call, the method setData!) cannot 
be invoked. Similarly, getData!) cannot be called after setData!). The constructor takes 
the object to state U_Data, while setData!) requires state F_Data. Using the model checker, 
the reachability analysis is able to expose the error, by signaling that the adjacency graph 
on typestates is disconnected. 


17 




The root cause of the semantic error is not just the incomplete adjacency matrix on 
typestates in the first dimension. The attempt to follow access permissions by manipulating 
typestates on the second dimension is bound to fail, as access permissions provide a much 
more expressive environment, by means of transformations (upgrades/downgrades), whereas 
the typestate predicates can operate only with equality. For this reason, in the correct 
implementation the second dimension is dropped. Figures 8 and 9 present a working version 
of this specification. 

The specification of mttsTaskDataX. java contains no typestates (which is in fact en- 
coded in practice with a single default value alive) and seven methods (including the con- 
structor). 


public class MttsTaskDataX { 
private int task.ID ; 
private int t as k _p r i o r i t y ; 
private Set task-dependencies; 

@Perm( ensures=" unique (this) ") 
MttsTaskDataX ( ) { ... } 

@Full 

void setID(int id) 

{ task_ID=id ; } 

@Full 

void s e t P r i o r i t y ( int priority) 

{ task_prior ity=priority ; } 

@Full 

void set D ependencies ( Set dependencies) 
{ task_dependencies=dependencies ; } 

@Pure 

int getID(int id) { ... } 

@Full 

int ge t P r io r i t y ( ) { ... } 

@Full 

Set get Dependencies ( ) { ... } 

} 


Figure 9. Specification of mttsTaskDataX. java 


A listing of the model generator for this application (with two classes) is given in Ap- 
pendix C. This more advanced version paves the way for full automation with templates 
for starting/ending generic methods and dealing with parameters. 

For reference, we have run scalability experiments on the complete mttsTask model. 
We list the size of the state space and the total verification time for each K . Note that in 
practice it is sufficient to use K < 6. The table shows that the model checker can easily 
handle extremely large state spaces: more than 10 3 ' states in less than a minute. 

6 Future Work 

There are several extensions (and refinements) possible to our basic approach. First and fore- 
most, we need to incorporate the additional constraints that class relationships (inheritance, 
containment) impose on state transitions rules; Access permission of method arguments also 
impact the analysis but is not currently taken into account. We consider that an incremental 
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K 

# states 

time (sec.) 

K 

# states 

time (sec.) 

1 

1.7 x 10 4 

0.03 

11 

1.3 x 10 22 

3.80 

2 

1.5 x 10 6 * 

0.12 

12 

6.6 x 10 23 

4.62 

3 

1.2 x 10 8 

0.27 

13 

3.1 x 10 25 

5.40 

4 

8.4 x 10 9 

0.48 

14 

1.4 x 10 27 

6.70 

5 

5.4 x 10 11 

0.73 

15 

6.5 x 10 28 

7.52 

6 

3.3 x 10 13 

1.07 

16 

2.9 x 10 3 ° 

9.26 

7 

1.8 x 10 15 

1.49 

17 

1.2 x 10 32 

9.80 

8 

1.0 x 10 17 

1.98 

18 

5.5 x 10 33 

11.37 

9 

5.4 x 10 18 

2.49 

19 

2.3 x 10 35 

13.19 

10 

2.7 x 10 2 ° 

3.18 

20 

1.0 x 10 37 

14.28 


Figure 10. Experimental results: scalability for the mttsTask model. 


refinement of the overall abstraction is possible, by augmenting the models with member 
variables, explicit typestate invariants, etc. One instance is to avoid explicitly encoding the 
access permissions into the states for all possible combinations, but instead use a deductive 
method (theorem proving, SMT solver) to “decide” if one can transition from a particular 
pre-access-permission to a particular post-access-permission. We would also like to explore 
the possibility of representing access permission fractions explicitly in a model, which would 
therefore require abandoning the traditional model checking framework, that only employs 
discrete-state systems, and using more powerful, deductive techniques: SAT/SMT solvers 
or automated theorem provers. We plan to implement our approach as part of the Plural 
tool. 

Aknowledgments. We would like to thank Ijaz Ahmad for the many constructive com- 
ments that helped improve the text and for his contributions to the model generator code. 
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Appendix A 


C program to generate the producer/consumer model 
for evmdcLsmc 


Note that, in this example, we have only one class definition, therefore, for simplicity, we 
can ignore the subscript i that identifies references to object i. Only superscript j, ranging 
from 0 to K, will appear. 

#include <stdio.h> 

#include <stdlib.h> 

#include <string.h> 


#def ine UNDEF 0 
#def ine UNIQUE 1 
#def ine FULL 2 
#def ine SHARED 3 
#def ine PURE 4 
#def ine IMMUTABLE 5 
#def ine NUM.AP 5 

#def ine EMPTY 1 
#def ine PARTIAL 2 
#def ine FILLED 3 
#def ine NUM.STATES 3 

#def ine CONSTRUCTOR 1 
#def ine IS.EMPTY 2 
#def ine IS_FILLED 3 
#def ine PRODUCE 4 
#def ine CONSUME 5 
#def ine NUM_METHODS 5 

#define PRE 0 
#def ine POST 1 


int K ; 

void Init () { 

printf (" Declarations \n" ) ; 


printf ( " 

state 

[0, 4 /,d]\n", NUM.STATES ) ; 

printf ( " 

tkrB 

[0, °/.d]\n", K + 

l) ; 

printf ( " 

tkwB 

[0, 4 / 0 d]\n\n", 

K + l) ; 

for (int i 

n 

o 

H- 

A 

II 

i++) { 


printf ( ' 

pc_°/,d 

[0, 1 ] \ n " , 

i) ; 

printf ( ' 

method. 

°/.d [0, 4 /,d]\n", 

i, NUM.METHODS ) 

printf ( ' 

ap_°/,d 

[0, % d ] \ n " , 

i, NUM.AP ) ; 

printf ( 1 

tkr_°/ 0 d 

[0, % d ] \ n " , 

i , K+l) ; 

printf ( ' 

} 

tkw_°/ 0 d 

[0, 4 /,d]\n\n 

" , i , K+l) ; 

printf ( " In 

itial states\n") ; 


printf ( " 

state 

= °/,d\n", UNDEF) 

; 

printf ( " 

tkrB 

= °/,d\n", K + l) ; 


printf ( " 

tkwB 

= °/.d\n\n", K + l) 

; 

for (int i 

•H 

O 

i++) { 


printf ( ' 

pc_°/,d 

= 4 / 0 d\n" , i, 

POST) ; 

printf ( 1 

method. 

°/«d = 4 / 0 d\n" , i, 

UNDEF) ; 

printf ( 1 

ap_°/,d 

= 4 / 0 d\n" , i, 

UNDEF) ; 

printf ( ' 

tkr_°/ 0 d 

H 

o 

p 

H- 


printf ( 1 

tkw_°/ 0 d 

= 0\n\n ", i ) 

; 


> 

> 

void Trans Of 

printf (" Trans it ions \n" ) ; 
for (int i=0; i<=K; i++) { 
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// start constructor , unique access 
printfC start _constructor_'/,d : \n" , i); 
printfC ap_%d = 4 / 0 d" , i, UNDEF ) ; 

for (int j =0 ; j< = K; j++) if (i!=j) printf(" /\\ ap_%d = °/ 0 d" , j, UNDEF); 
pr int f ( " -> " ) ; 

printfC pc_ 4 /.dV = 4 / 0 d /\\ method_7.d\ ’ = 4 / 0 d /\\ ap_%dV = 4 / 0 d" , i, PRE , i, 
CONSTRUCTOR, i, UNIQUE); 

printfC /\\ tkrBV = 0 /\\ tkwBV = 0 /\\ tkr_ 4 /,dV = °/ 0 d /\\ tkw_°/ 0 dV = 4 / 0 d\n" , i, K 
+1, i, K+l ) ; 

// start isEmpty () , 1 read token available 

printfC start_is_empty_ 4 / 0 d : \n" , i); 

pr int f ( " p c _ % d = 4 /.d /\\ ap_°/„d != °/,d /\\ tkrB > 0", i, POST, i, UNDEF); 
pr int f ( " -> " ) ; 

pr int f ( " p c _ % d \ ’ = 4 /,d /\\ method. °/.d\ * = 4 /,d /\\ ap_ 4 /.dV = 4 /.d" , i, PRE, i, IS.EMPTY , 
i, PURE); 

printfC /\\ tkr_ 4 / 0 dV = 1 /\\ tkrBV = tkrB - l\n" , i); 

// start isFilled () , 1 read token available 
printfC start_is_f illed_ 4 / 0 d : \n" , i); 

pr int f ( " pc_ 4 /,d = °/.d /\\ ap_°/,d != °/,d /\\ tkrB > 0", i, POST, i, UNDEF); 

pr int f ( " -> " ) ; 

pr int f ( " pc.y.dV = 4 /,d /\\ method_°/,dV = 4 / 0 d /\\ ap_ 4 /.dV = 4 /.d" , i, PRE, i, IS.FILLED , 
i, PURE); 

printfC /\\ tkr_°/ 0 dV = 1 /\\ tkrBV = tkrB - l\n" , i); 

// start produceO, enough tokens exist 
printfC start _produce_7,d : \n" , i); 

printfC pc_y o d = 4 / 0 d /\\ ap_°/ 0 d != °/ 0 d /\\ (state = 4 / 0 d \\/ state = °/ 0 d) " , i, POST, i, 
UNDEF, EMPTY, PARTIAL); 
printf(" / \ \ tkrB > 0 /\\ tkwB = 7«d" , K + l); 
pr int f ( " -> " ) ; 

printf(" pc_ 4 /,dV = 4 /«d /\\ method_ 4 / 0 dV = 4 / 0 d /\\ ap_%dV = 7.d" , i, PRE, i, PRODUCE, i 
, FULL); 

printf(" / \ \ tkwBV = 0 /\\ tkrBV = tkrB - 1 /\\ tkr_ 4 / 0 dV = 1 /V tkw_ 4 / 0 dV = 4 / 0 d\n" 
, i, i, K+l); 

// start consumeO, enough tokens exist 
printf(" start _consume_%d : \n" , i); 

printfC" pc_%d = %d /\\ ap_°/ 0 d != °/ 0 d /\\ (state = °/ 0 d \\/ state = 4 / 0 d) " , i, POST, i, 
UNDEF, FILLED, PARTIAL); 
printfC /V tkrB > 0 /\\ tkwB = °/ 0 d" , K + l); 
pr int f ( " -> " ) ; 

printfC pc_ 4 /,dV = 4 /od /\\ method_ 4 / 0 dV = 4 / 0 d /\\ ap_%dV = 4 / 0 d" , i, PRE, i, CONSUME, i 
, FULL); 

printfC /V tkwBV = 0 /\\ tkrBV = tkrB - 1 /\\ tkr_°/ 0 dV = 1 /V tkw_°/ 0 dV = 4 /od\n" 
, i , i , K + l) ; 

// end methods 

printfC end.const ruct or _ 4 / 0 d : \n " , i); 

printfC pc_y o d = °/ 0 d /\\ method_y«d = °/ 0 d -> pc_ 4 / 0 dV = °/«d /\\ state V = y o d" , i, PRE, 

i, CONSTRUCTOR, i, POST, EMPTY); 

printfC /V tkrB’ = 4 / 0 d /\\ tkwBV = °/ 0 d /\\ tkr_%dV = 0 /\\ tkw_ 4 / 0 d\’ = 0\n" , K + l, 
K+l, i, i); 

printfC end_is_empty_ 4 / 0 d : \n" , i); 

printfC pc_y o d = 4 / 0 d /\\ method_y o d = 4 / 0 d -> pc.y.dX’ = °/ 0 d" , i, PRE, i, IS.EMPTY , i, 

POST) ; 

printfC /V tkrB’ = tkrB + 1 /\\ tkr_ 4 / 0 dV = 0\n" , i); 
printfC end_is_f illed_%d : \n" , i); 

printfC pc_%d = 4 / 0 d /\\ method_%d = %d -> pc_ 4 / 0 dV = 7.d" , i, PRE, i, IS.FILLED , i, 

POST) ; 

printfC /V tkrB’ = tkrB + 1 /\\ tkr_ 4 / 0 dV = 0\n" , i); 
printfC end_produce_lst_ 4 / 0 d : \n" , i); 

printfC pc_y o d = °/ 0 d /\\ method_y«d = °/ 0 d /\\ state = 4 / 0 d -> pc_%d\’ = %d /\\ state \ ’ 

= 4 /,d" , i, PRE, i, PRODUCE, EMPTY, i, POST, PARTIAL); 
printfC /V tkrB’ = tkrB + 1 /\\ tkwBV = 4 /.d /\\ tkr_°/ 0 dV = 0 /\\ tkw_ 4 / 0 dV = 0\n" , 
K+l , i , i) ; 

printfC end_produce_7.d:\n" , i); 

printfC pc_y o d = 4 / 0 d /\\ method_y o d = °/ 0 d /\\ state = %d -> pc.ydX’ = %d /\\ (state 

\» = 4 /,d \\/ st at e \ ’ = 4 /.d)", i, PRE, i, PRODUCE, PARTIAL, i, POST, PARTIAL, 

FILLED) ; 

printfC /V tkrB’ = tkrB + 1 /\\ tkwBV = 4 /.d /\\ tkr.yodX’ = 0 /\\ tkw.yodX’ = 0\n" , 
K+l , i , i) ; 

printfC end_consume_f ull_ 4 / 0 d : \n" , i); 
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printfC" pc_%d = °/ 0 d /\\ method_%d = °/ 0 d /\\ state = %d -> pc.ydX’ = %d /\\ state\ 
= %d" , i, PRE , i, CONSUME, FILLED, i, POST, PARTIAL); 
printfC" /\\ tkrB ’ = tkrB + 1 /\\ tkwBV = %d /\\ tkr.ydV = 0 /\\ tkw.ydV = 0\n" 
K+l , i , i) ; 

printfC" end_consume_°/ 0 d : \n" , i); 

printfC" pc_y„d = °/ 0 d /\\ method_y o d = %d /\\ state = %d -> pc_%d\’ = %d /\\ (state 
V = °/,d \\/ st at e \ ’ = y„d) " , i, PRE, i, CONSUME, PARTIAL, i, POST, PARTIAL, 
EMPTY) ; 

printf(" /\\ tkrB’ = tkrB + 1 /\\ tkwBV = %d /\\ tkr.'/odV = 0 /\\ tkw.yodV = 0\n" 
K+l , i , i) ; 

// create alias, read tokens exist 
printfC" creat e_alias_°/ 0 d : \n" , i); 

printfC" ap_°/,d = °/.d /\\ tkrB > 0 /\\ state != “/.d" , i, UNDEF , UNDEF ) ; 
pr int f ( " -> " ) ; 

printfC" pc_y.dV = */od /\\ method.yodX’ = 4 / 0 d /\\ ap_y o d\’ = %d\n" , i, POST, i, UNDEF, 
i, PURE); 


void Spec () { 

printf ( " Pr opert ies \n " ) ; 
printfC" ! EX ( true ) \n" ) ; 


int main (int argc , char *argv[]) 

{ 

K = 5; 

for (int i = 1; i < argc; ++i) { 

if ( strcmp ( argv [i] , "-k")==0 && i<argc-l) { 

K = atoi (argv [i + 1] ) ; 
if (K <0) { 

f printf ( stderr , " ERROR: invalid number of references, %d.\n" , K) ; 

f printf ( stderr , " need at least 1 reference An") ; 

return 2; 

> 

> 

> 

Init () ; 

Trans ( ) ; 

Spec () ; 
return 0; 

> 
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Appendix B 


An example generated evmdcLsmc model 


Below is an instance of a generated producer/consumer model, for parameter K = 2. 


Declarations 


state 


[0, 

3] 

tkrB 


[0, 

3] 

tkwB 


[0, 

3] 

pc_0 


[0, 

1] 

method 

_0 

[0, 

6] 

ap_0 


[0, 

5] 

tkr _0 


[0, 

3] 

tkw_0 


[0, 

3] 

pc_l 


[0, 

1] 

method 

_1 

[0, 

5] 

ap_l 


[0, 

6] 

tkr _ 1 


[0, 

3] 

tkw_ 1 


[0, 

3] 

pc_2 


[0, 

1] 

method 

_ 2 

[0, 

5] 

ap_2 


[0, 

6] 

tkr _2 


[0, 

3] 

tkw_2 


[0, 

3] 

Initial 

states 


state 


= 0 


tkrB 


= 3 


tkwB 


= 3 


pc_0 


= 1 


method 

_0 

= 0 


ap_0 


= 0 


tkr _0 


= 0 


tkw_0 


= 0 


pc_l 


= 1 


method 

_1 

= 0 


ap_l 


= 0 


tkr _ 1 


= 0 


tkw_ 1 


= 0 


pc_2 


= 1 


method 

_ 2 

= 0 


ap_2 


= 0 


tkr _2 


= 0 


tkw_2 


= 0 



Transitions 
start .construct or _0 : 


ap_0 

= 0 /\ ap.l = 0 


/\ 

ap_2 = 

‘ o - 

> 











pc_0 

’ = 0 /\ method. 

0 

’ = 

1 /\ 

ap.O ’ 

= 

1 

A 

tkrB ’ 

= 0 

/\ tkwB * 

= 

0 /\ 

tkr.O * 

= 3 

/\ 


tkw.O ’ = 3 
















start. 

is.empty.O : 
















pc_0 

= 1 /\ ap_0 ! = 

0 

/\ 

tkrB 

> 0 

-> 











pc_0 

’ = 0 /\ method. 

0 

’ = 

2 /\ 

ap.O ’ 

= 

4 

A 

tkr.O 

’ = 

1 /\ tkrB : 

’ = 

tkrB 

- 1 



start. 

is.f illed.O : 
















pc.O 

= 1 /\ ap.O ! = 

0 

/\ 

tkrB 

> 0 

-> 











pc.O 

’ = 0 /\ method. 

0 

’ = 

3 /\ 

ap.O ’ 

= 

4 

A 

tkr.O ; 

’ = 

1 /\ tkrB : 

’ = 

tkrB 

- 1 



start. 

produce.O : 
















pc.O 

= 1 /\ ap.O ! = 

0 

/\ 

(state = 1 

\/ 


state 

= 2) 

/\ 

tkrB > 0 

/\ 

tkwB 

= 3 

-> 


pc.O 

’ = 0 /\ method. 
1 /\ tkw.O ’ = 3 

0 

’ = 

4 A 

ap.O ’ 

= 

2 

/\ 

tkwB ’ 

= 0 

/\ tkrB ’ 

= 

tkrB 

- 1 /\ 

tkr. 

0 » 

start. 

consume.O : 
















pc.O 

= 1 /\ ap.O ! = 

0 

/\ 

(state = 3 

\/ 


state 

= 2) 

/\ 

tkrB > 0 

/\ 

tkwB 

= 3 

-> 


pc.O 

’ = 0 /\ method. 

0 

’ = 

B A 

ap.O ’ 

= 

2 

A 

tkwB * 

= 0 

/\ tkrB ’ 

= 

tkrB 

- 1 /\ 

tkr. 

0 » 


1 /\ tkw_0 ’ = 3 
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end_construct or_0 : 

pc_0 = 0 /\ me t hod_0 =1 -> 

pc_0 ’ = 1 /\ state ’ = 1 /\ tkrB ’ = 3 /\ tkwB ’ = 3 /\ tkr_0 ’ = 0 /\ tkw_0 ’ = 0 

end_is_empty_0 : 

pc_0 = 0 /\ me t hod_0 =2 -> 

pc_0 ’ = 1 /\ tkrB ’ = tkrB + 1 /\ tkr_0 ’ = 0 

end_is_filled_0 : 

pc_0 = 0 /\ me t hod_0 =3 -> 

pc_0 ’ = 1 /\ tkrB ’ = tkrB + 1 /\ tkr_0 ’ = 0 

end_produce_lst_0 : 


pc.O = 0 

/\ method.O = 4 

A 

state 

= 1 -> 











pc.O ’ = 1 

/\ state ’ = 2 

A 

tkrB ’ 

= tkrB + 

1 /\ 

tkwB 

’ = 3 

/\ 

tkr.O ’ = 

0 

/\ 

tkw.O ’ 

= 

0 

end.produce 

.0 : 














pc.O = 0 

/\ method.O = 4 

A 

state 

= 2 -> 











pc.O ’ = 1 

/\ (state’ = 2 

\/ 

state 

’ = 3) /\ 

tkrB 

’ = 

tkrB + 

1 

/\ tkwB ’ 

= 

3 

/\ tkr _ 

0 ’ 

= 

0 /\ 

tkw.O ’ = 0 














end.consume 

_f ull.O : 














pc.O = 0 

/\ method.O = 5 

A 

state 

= 3 -> 











pc.O ’ = 1 

/\ state ’ = 2 

A 

tkrB ’ 

= tkrB + 

1 /\ 

tkwB 

’ = 3 

/\ 

tkr.O ’ = 

0 

/\ 

tkw.O ’ 

= 

0 

end.consume 

.0 : 














pc.O = 0 

/\ method.O = 5 

A 

state 

= 2 -> 











pc.O ’ = 1 

/\ (state’ = 2 

\/ 

state 

’ = 1) /\ 

tkrB 

* = 

tkrB + 

1 

/\ tkwB ’ 

= 

3 

/\ tkr. 

0 ’ 

= 


0 /\ tkw_0 ’ = 0 


create_alias_0 : 

ap_0 = 0 /\ tkrB > 0 /\ state != 0 -> 

pc_0 ’ = 1 /\ method_0 ’ = 0 /\ ap_0 ’ = 4 
start .construct or_ 1 : 

ap_ 1 = 0 /\ ap_0 = 0 /\ ap_2 = 0 -> 


pc. 1 

’ = 0 /\ method. 

1 ; 

’ = 

1 A 

ap.l ’ 

= 

1 

A 

tkrB ’ 

= 0 

/\ tkwB ’ 

= 

0 /\ 

tkr. 

i ’ 

= 3 

/\ 


tkw. 1 ’ = 3 

















start. 

is.empty. 1 : 

















pc. 1 

= 1 /\ ap.l ! = 

0 

/\ 

tkrB 

> 0 

-> 












pc. 1 

’ = 0 /\ method. 

1 ; 

’ = 

2 A 

ap.l ’ 

= 

4 

A 

tkr. 1 

’ = 

1 /\ tkrB : 

’ = 

tkrB 

- 1 




start. 

is.f illed. 1 : 

















pc. 1 

= 1 /\ ap.l ! = 

0 

/\ 

tkrB 

> 0 

-> 












pc. 1 

’ = 0 /\ method. 

1 ; 

’ = 

3 A 

ap.l ’ 

= 

4 

A 

tkr. 1 

’ = 

1 /\ tkrB : 

’ = 

tkrB 

- 1 




start. 

produce. 1 : 

















pc. 1 

= 1 /\ ap.l ! = 

0 

/\ 

(state = 1 

\/ 


state 

= 2) 

/\ 

tkrB > 0 

/\ 

tkwB 

= 3 


-> 


pc. 1 

’ = 0 /\ method. 
1 /\ tkw. 1 ’ = 3 

1 ; 

= 

4 A 

ap.l ’ 

= 

2 

/\ 

tkwB ’ 

= 0 

/\ tkrB’ 

= 

tkrB 

- 1 

A 

tkr. 

1 ’ = 

start. 

consume. 1 : 

















pc. 1 

= 1 /\ ap.l ! = 

0 

/\ 

(state = 3 

\/ 


state 

= 2) 

/\ 

tkrB > 0 

/\ 

tkwB 

= 3 


-> 


pc. 1 

’ = 0 /\ method. 

1 ; 

’ = 

B A 

ap.l ’ 

= 

2 

A 

tkwB ’ 

= 0 

/\ tkrB’ 

= 

tkrB 

- 1 

A 

tkr. 

1 ’ = 


1 /\ tkw_ 1 * = 3 


end.construct or_ 1 : 

pc_ 1 = 0 /\ method. 1 =1 -> 

pc.l’ = 1 /\ state’ = 1 /\ tkrB’ =3 /\ tkwB’ =3 /\ tkr.l’ = 0 /\ tkw.l’ = 0 

end_is_empty_ 1 : 

pc_ 1 = 0 /\ method. 1 =2 -> 

pc.l’ =1 /\ tkrB’ = tkrB + 1 /\ tkr.l’ = 0 

end. is_f illed. 1 : 

pc. 1 = 0 /\ method. 1 =3 -> 

pc.l’ =1 /\ tkrB’ = tkrB + 1 /\ tkr.l’ = 0 

end.produce.lst.l : 


pc.l = 0 /\ method.l 

= 4 

A 

state 

= 1 -> 










pc.l ’ = 1 /\ state ’ 

= 2 

A 

tkrB ’ 

= tkrB + 

1 /\ 

tkwB 

’ = 3 

/\ 

tkr.l ’ = 

0 

/\ 

tkw. 1 ’ = 

0 

end.produce. 1 : 














pc.l = 0 /\ method.l 

= 4 

A 

state 

= 2 -> 










pc.l’ = 1 /\ (state’ 

= 2 

\/ 

state 

’ = 3) /\ 

tkrB 

’ = 

tkrB + 

1 

/\ tkwB ’ 

= 

3 

/\ tkr.l’ 

= 

0 /\ tkw. 1 ’ = 0 














end.consume.f ull. 1 : 














pc.l = 0 /\ method.l 

= 5 

A 

state 

= 3 -> 










pc.l ’ = 1 /\ state ’ 

= 2 

A 

tkrB ’ 

= tkrB + 

1 /\ 

tkwB 

’ = 3 

/\ 

tkr.l’ = 

0 

/\ 

tkw. 1 ’ = 

0 

end.consume. 1 : 














pc.l = 0 /\ method.l 

= 5 

A 

state 

= 2 -> 










pc.l’ = 1 /\ (state’ 

= 2 

\/ 

state 

’ = 1) /\ 

tkrB 

* = 

tkrB + 

1 

/\ tkwB ’ 

= 

3 

/\ tkr.l’ 

= 


0 /\ tkw. 1 ’ = 0 


creat e.al ias. 1 : 

ap.l = 0 /\ tkrB > 0 /\ state != 0 -> 

pc.l’ = 1 /\ method.!.’ = 0 /\ ap.l’ = 4 
start .construct or_2 : 

ap_ 2 = 0 /\ ap.O = 0 /\ ap.l = 0 -> 

pc_2 ’ = 0 /\ method_2 ’ = 1 /\ ap_2 ’ = 1 /\ tkrB ’ = 0 /\ tkwB ’ = 0 /\ tkr_2 ’ = 3 /\ 

tkw_2 ’ = 3 
start_is_empty_2 : 
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pc_2 = 1 /\ ap_2 != 

0 

/\ 

tkrB 

> 0 

-> 










pc_2 ’ = 0 /\ method. 
start_is_filled_2 : 

2 ; 

= 

2 /\ 

ap_2 ’ 

= 

4 

A 

tkr_2 ; 

’ ” 

1 /\ tkrB : 

’ = tkrB 

- 1 



pc_2 = 1 /\ ap_2 != 

0 

/\ 

tkrB 

> 0 

-> 










pc_2 ’ = 0 /\ method, 
start _produce_2 : 

2 ; 

= 

3 /\ 

ap_2 ’ 

= 

4 

A 

tkr_2 ; 

’ = 

1 /\ tkrB : 

’ = tkrB 

- 1 



pc_2 = 1 /\ ap_2 != 

0 

/\ 

(state = 1 

\/ 


state 

= 2) 

/\ 

tkrB > 0 

/\ tkwB 

= 3 

-> 


pc_2 ’ = 0 /\ method. 

2 ; 

’ = 

4 A 

ap_2 ’ 

= 

2 

/\ 

tkwB ’ 

= 0 

/\ tkrB ’ 

= tkrB 

- 1 /\ 

tkr _ 

2 5 = 

1 /\ tkw_2 ’ = 3 















start _consume_2 : 















pc_2 = 1 /\ ap_2 != 

0 

/\ 

(state = 3 

\/ 


state 

= 2) 

/\ 

tkrB > 0 

/\ tkwB 

= 3 

-> 


pc_2 ’ = 0 /\ method. 

2 ; 

’ = 

B A 

ap_2 ’ 

= 

2 

A 

tkwB ’ 

= 0 

/\ tkrB ’ 

= tkrB 

- 1 /\ 

tkr. 

2 ’ = 


1 /\ tkw_2 ’ = 3 


end.construct or_2 : 

pc_2 = 0 /\ method_2 =1 -> 

pc_2 ’ = 1 /\ state ’ = 1 /\ tkrB ’ = 3 /\ tkwB ’ = 3 /\ tkr_2 5 = 0 /\ tkw_2 ’ = 0 

end_is_empty_2 : 

pc_2 = 0 /\ method_2 =2 -> 

pc_2 ’ = 1 /\ tkrB ’ = tkrB + 1 /\ tkr_2 ’ = 0 

end_is_filled_2 : 

pc_2 = 0 /\ method_2 =3 -> 

pc_2 ’ = 1 /\ tkrB ’ = tkrB + 1 /\ tkr_2 ’ = 0 

end_produce_lst_2 : 


pc_2 = 0 

/\ method_2 = 4 

A 

state 

= 1 -> 











pc_2 ’ = 1 

/\ state ’ = 2 

A 

tkrB ’ 

= tkrB + 

1 /\ 

tkwB 

’ = 3 

/\ 

tkr .2 ’ = 

0 

/\ 

tkw_2 ’ 

= 

0 

end.produce 

.2 : 














pc_2 = 0 

/\ method_2 = 4 

A 

state 

= 2 -> 











pc_2 ’ = 1 

/\ (state’ = 2 

\/ 

state 

’ = 3) /\ 

tkrB 

’ = 

tkrB + 

1 

/\ tkwB ’ 

= 

3 

/\ tkr. 

2 ’ 

= 

0 /\ 

t kw_ 2 ’ = 0 














end.consume 

_full_2 : 














pc_2 = 0 

/\ method_2 = 5 

A 

state 

= 3 -> 











pc_2 ’ = 1 

/\ state ’ = 2 

A 

tkrB ’ 

= tkrB + 

1 /\ 

tkwB 

’ = 3 

/\ 

tkr .2 ’ = 

0 

/\ 

tkw_2 ’ 

= 

0 

end.consume 

.2 : 














pc_2 = 0 

/\ method_2 = 5 

A 

state 

= 2 -> 











pc_2 ’ = 1 

/\ (state’ = 2 

\/ 

state 

’ = 1) /\ 

tkrB 

’ = 

tkrB + 

1 

/\ tkwB ’ 

= 

3 

/\ tkr. 

2 ’ 

= 


0 /\ tkw_2 ’ = 0 


create_alias_2 : 

ap_2 = 0 /\ tkrB > 0 /\ state != 0 -> 

pc_2 ’ = 1 /\ method_2 ’ = 0 /\ ap_2 ’ = 4 
Properties 
! EX (true ) 
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Appendix C 


The generator for the mttsTask model 


#include <stdio.h> 
#include <stdlib.h> 
#include <string.h> 

int K ; 


#def ine UNDEF 0 

#def ine UNIQUE 1 

#def ine FULL 2 

#def ine SHARED 3 

#def ine PURE 4 

#def ine IMMUTABLE 5 

#def ine NUM.AP 5 

#define PRE 0 

#def ine POST 1 

//MttsTask . java States 
#def ine CREATED 1 

#def ine READY 2 


#def ine COMPLETE 3 
#def ine DESTROYED 4 
#def ine NUM_ STATES _Mt t sT ask 4 

//MttsTask . java methods 

#define MttsTask 1 

#define setData 2 

#define getData 3 

#define execute 4 

#def ine DELETE 5 

#def ine NUM_METHODS_Mtt sTask 5 

//MttsTaskDataX . java states 

#def ine ALIVE 1 

#def ine NUM_ STATES _Mt t sTaskDataX 1 

//MttsTaskDataX . java methods 


#define MttsTaskDataX 1 
#define setID 2 
#define setPriority 3 
#define setDependencies 4 
#define getID 5 
#define getPriority 6 
#define getDependencies 7 


#def ine NUM_ METHODS .MttsTaskDataX 7 

#define Mtt sTask.CLASS 0 

#define Mtt sTaskDat aX.CLASS 1 
#def ine NUM.CLASSES 2 

const int NUM.STATES [NUM.CLASSES] = 

{ NUM_ STATES _Mtt sTask , NUM_ STATES .MttsTaskDataX } ; 
const int NUM.METHODS [NUM.CLASSES ] = 

{NUM_ METHODS .MttsTask , NUM.METHODS .MttsTaskDataX } ; 

void Init () { 

printf ( "Declarations\n" ) ; 

for (int i =0 ; i<NUM_CLASSES ; i++) { 


printf ( " 

state_7,d 

[0, 

°/.d] \ n" , i , 

, NUM.STATES [i] ) 

printf ( " 

tkrB. 4 / 0 d 

[0, 

7.d] \n" , i , 

. K+l ) ; 

printf ( " 

tkwB_ 4 / 0 d 

[0, 

%d] \n\n " , 

i , K+l) ; 

for (int 

j=0; j<=K; 

j ++ ) 

{ 



printf ( " 

pc_y.d_ 0 /,d 

[0, 

1] \n" , i , j ) ; 


printf ( " 

me t ho d_ °/ 0 d_ °/ 0 d 

[0, 

%d] \n " , i , j , 

NUM.METHODS [i] ) 

printf ( " 

ap_ 0 /od_y o d 

[0, 

°/,d] \ n " , i , j , 

NUM.AP ) ; 

printf ( " 

tkr_y o d_y o d 

[0, 

°/.d] \ n" , i , j , 

K + l) ; 

printf ( " 

tkw_y o d_y o d 

[0, 

°/.d] \n\n " , i , 

j , K + l) ; 


> 
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> 

pr int f ( " Init ial states\n") ; 

for (int i =0 ; i<NUM_CLASSES ; i++) { 

printf(" state_%d = 4 / 0 d\n" , i, UNDEF); 
printf(" tkrB_ 4 / 0 d = %d\n" , i, K + l) ; 

printf(" tkwB_°/ 0 d = %d\n\n" , i, K + l); 

for (int j =0 ; j<=K; j++) { 

printf(" pc_ 4 /od_ 4 / 0 d = 4 / 0 d\n" , i, j, POST); 

printf(" method_ 4 /od_ 4 / 0 d = 4 / 0 d\n" , i, j, UNDEF); 

printf(" ap_ 4 /od_ 4 / 0 d = 4 / 0 d\n" , i, j, UNDEF); 

printf(" tkr_ 4 /od_ 4 / 0 d = 0\n" , i, j); 

printf(" tkw_ 4 /od_ 4 / 0 d = 0\n\n" , i, j); 

> 

> 

> 

void start .construct or ( int classID , const char* name, int id, int state, int j ) 

{ 

printf(" st art _ 4 / 0 s_ 4 / 0 d : \t " , name , j ) ; 
for (int k=0; k<=K; k++) { 

if (k ! =K) printfC ap_ 4 /,d_ 4 /.d = 4 /,d /\\ ", classID , k, UNDEF); 
else printfC ap_ 4 / 0 d_ 4 / 0 d = °/ 0 d" , classID, k, UNDEF); 

> 

pr int f ( " -> " ) ; 

printfC pc_ 4 / 0 d_%d\ ’ = 4 / 0 d /\\ method_ 4 / 0 d_ 4 / 0 d\ ’ = %d", classID, j, PRE , classID, j, id); 
printfC /\\ ap_ 4 /od_ 4 / 0 d\ ’ = %d /\\ tkrB_Zd\ ’ = 0 /\\ tkwB_%d\’ = 0 /\\ tkr_ 4 / 0 d_ 4 / 0 d\ ’ = °/ 0 d 
/\\ tkw_%d_ 4 / 0 d\ ’ = °/ 0 d\n ", class ID , j, UNIQUE , classID , classID , classID, j, K + l , classID 
, j , K+l) ; 


void end.construct or ( int classID , const char* name, int id, int state, int j ) 

{ 

printfC end_7,s_7,d : \t " , name , j); 

printfC pc_ 4 /od_%d = °/ 0 d / \ \ method. 4 / 0 d_ 4 / 0 d = °/ 0 d ", classID, j, PRE, class ID , j , id ) ; 

pr int f ( " -> " ) ; 

printfC pc.Xd.'/odV = °/ 0 d" , classID, j, POST); 

if (state !=-l) printfC /\\ state_%d\’ = 4 / 0 d ", classID , state ) ; 

printf(" /\\ tkrB_%d’ = °/ 0 d /\\ tkwB_%d\’ = 4 / 0 d /\\ tkr_ 4 / 0 d_ 4 / 0 d\ ’ = 0 /\\ tkw_ 4 / 0 d_ 4 / 0 d\ ’ = 0\ 
n", classID, K + l, classID, K + l , classID , j, classID, j); 

> 

void start _ap_st ate ( int classID, int ap , int state, int j) 

{ 

if ( ap == FULL ) 

printfC /\\ ap_ 4 /od_ 4 / 0 d != 4 / 0 d /\\ tkrB_ 4 / 0 d > 0 /\\ tkwB_°/ 0 d = 4 / 0 d" , classID, j, UNDEF, 
classID , classID , K + l); 
else if ( ap == PURE ) 

printfC /\\ ap_ 4 /od_ 4 / 0 d != %d /\\ tkrB_°/ 0 d > 0", classID, j, UNDEF , classID ) ; 
if (state !=-l) printfC /\\ state_%d = °/ 0 d ", classID , state ) ; 

//-l means no state 


void st art _ap_st at e_pr ime ( int classID, int ap , int state, int j) 

{ 

if ( ap == FULL ) 

printfC /\\ ap_ 4 /od_ 4 / 0 d\ ’ = %d /\\ tkwB.'/odV = 0 /\\ tkrB.y.dV = tkrB_°/ 0 d - 1 /\\ tkr_ 4 / 0 
d-'/odV = 1 /\\ tkw_ 4 /od_ 4 / 0 d \ * = %d" , classID , j , FULL , classID , classID , classID , classID , 
j, classID, j, K + l); 
else if ( ap == PURE ) 

printfC /\\ ap_ 4 /od_ 4 / 0 d\ ’ = 4 / 0 d /\\ tkrB_%d\’ = tkrB_ 4 / 0 d - 1 /\\ tkr_ 4 / 0 d_ 4 / 0 d\ ’ = 1", 
classID ,j , PURE , classID , classID , classID ,j) ; 

> 

void end_ap_st ate.pr ime ( int classID, int ap , int state, int j) 

{ 

if (state !=-l) printfC /\\ state.'/odV = °/ 0 d ", classID , state ) ; 
if ( ap == FULL ) 

printfC /\\ tkrB_%d’ = tkrB_ 4 / 0 d + 1 /\\ tkwB_ 4 / 0 d\’ = 4 / 0 d /\\ tkr_ 4 / 0 d_ 4 / 0 d\ ’ = 0 /\\ 
tkw_ 4 / 0 d_ 4 / 0 d\ ’ = 0 ", classID , classID , classID , K + l , classID , j , classID , j); 
else if ( ap == PURE ) 

printfC /\\ tkrB.yod’ = tkrB_ 4 / 0 d + 1 /\\ tkr _%d_ 4 / 0 d\ ’ = 0 ", classID , classID , classID , 

j); 

> 
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void start _method ( int classID , const char* name, int id, int ap , int state, int* 
ap.parameteres , int* st.parametres , int size, int j) 

{ 

printf(" start_ 0 / o s_°/od : \t " , name , j ) ; 
printf(" pc_ 4 /„d_ 4 / 0 d = °/ 0 d ", classID, j, POST); 
start_ap_state(classID , ap , state ,j) ; 

// if method does not have parameter, this code does not have any effect 
if ( j == 0) { 

int subscript=l; 
for (int i=0; i<size;i++) { 
subscript ++ ; 

start_ap_st ate (subscript ,ap_parameteres [i] , st.parametres [i] ,j) ; 

> 

> 

pr int f ( " -> " ) ; 

printf(" pc_°/od_%d\ ’ = 4 / 0 d /\\ method_ 0 /od_ 4 /od\ ’ = %d" , classID , j, PRE , classID , j, id); 
start_ap_state_prime (classID , ap , state ,j) ; 
if ( j == 0 ) { 

int subscript=l; 
for (int i=0; i<size;i++) { 
subscript ++ ; 

start_ap_state_prime( subscript , ap.parameteres [i] , st.parametres [i] ,j) ; 

> 

> 

pr int f ( " \n " ) ; 

> 

void end_method ( int classID , const char* name, int id, int ap , int state, int* 
ap_parameteres , int* st.parametres, int size, int j) 

{ 

printf(" end_°/ 0 s_%d : \t " , name , j ) ; 

printf(" pc_°/od_%d = %d /\\ method_y o d_ 4 / 0 d = °/ 0 d ", class ID , j, PRE , classID , j, id); 
pr int f ( " -> " ) ; 

printf(" pc_ # /.d_y.d\» = 4 /od" , classID , j , POST); 
end_ap_state_prime(classID , ap , state ,j) ; 
if ( j == 0 ) { 

int subscript=l; 
for (int i=0; i<size;i++) { 
subscript ++ ; 

end. ap.st at e.prime (subscript ,ap_parameteres [i] .st.parametres [i] ,j) ; 

> 

> 

pr int f ( " \n " ) ; 

> 

void create.alias ( int classID , const char name [] , int j) 

{ 

printf(" create_alias_Zs_y,d:\t" , name , j ) ; 

printf(" ap_ 4 / 0 d_y o d = 4 / 0 d /\\ tkrB_ 4 / 0 d > 0 /\\ state_ 4 / 0 d != y o d" , classID , j , UNDEF , classID , 
classID , UNDEF) ; 
pr int f ( " -> " ) ; 

pr int f ( " pc_ 4 /,d_ 4 /,d\ » = 4 /,d /\\ method_ 4 /,d_ 4 /.d\ * = °/,d ", classID, j, POST , classID , j, UNDEF) 

printf(" /\\ ap_%d_%dV = %d\n ", classID , j, PURE); 

> 

void t r ans i t ions.f or.class _Mt t sTask ( int j) 

{ 

start_constructor(MttsTask_CLASS , "MttsTask" ,MttsTask , — 1 , j ) ; 

// -1 means, no required state 

start_method(MttsTask_CLASS , "setData" , setData , FULL , CREATED , NULL , NULL ,0 , j ) ; 
start_method(MttsTask_CLASS , "getData" ,getData , FULL , READY , NULL , NULL ,0 , j ) ; 
start_method(MttsTask_CLASS ."execute" , execute , FULL , READY , NULL , NULL ,0 , j ) ; 
start.method (MttsTask.CLASS , "delete" .DELETE .FULL .COMPLETE .NULL .NULL ,0, j) ; 

end_constructor(MttsTask_CLASS , "MttsTask" .MttsTask , CREATED , j ) ; 
end.method (MttsTask.CLASS , "setData" .setData , FULL , READY , NULL , NULL ,0 , j ) ; 

//To introduce syntax error, comment out the line above, uncomment the line below 
//and do the necessary changes in the MttsTask . java 

// end_method (MttsTask_CLASS , "setData" , setData , FULL , CREATED , NULL , NULL ,0, j) ; 

end.method (MttsTask.CLASS , "getData" , getData , FULL , READY , NULL , NULL ,0 , j ) ; 
end.method (MttsTask.CLASS , "execute" .execute , FULL .COMPLETE , NULL , NULL , 0 , j ) ; 
end.method (MttsTask.CLASS , "delete" .DELETE .FULL .DESTROYED .NULL .NULL ,0, j) ; 
create.alias (MttsTask.CLASS ."MttsTask" , j ) ; 
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> 


void transit ions_f or_class_Mtt sTaskDataX ( int j) 

{ 

start.constructor ( MttsTaskDataX_CLASS , "MttsTaskDataX" , MttsTaskDataX , -1 , j ) ; 

// -1 means, no required state 

start_method(MttsTaskDataX_CLASS , "setID" ,setID , FULL , -1 , NULL , NULL , 0 , j ) ; 
start_method(MttsTaskDataX_CLASS ,"setPriority" ,setPriority , FULL , -1 , NULL , NULL , 0 , j ) ; 
start_method(MttsTaskDataX_CLASS , " setDependencies " , setDependencies , FULL , -1 , NULL , NULL , 0 , 

j) ; 

start_method(MttsTaskDataX_CLASS , "getID" ,getID , PURE , -1 , NULL , NULL , 0 , j ) ; 
start_method(MttsTaskDataX_CLASS ,"getPriority" ,getPriority , PURE , -1 , NULL , NULL , 0 , j ) ; 
start_method(MttsTaskDataX_CLASS ,"getDependencies" ,getDependencies , PURE , -1 , NULL , NULL , 0 , 

j) ; 

end_constructor(MttsTaskDataX_CLASS , " MttsTaskDataX ".MttsTaskDataX ,ALIVE,j) ; 
end_method(MttsTaskDataX_CLASS , "setID" , setID , FULL , -1 , NULL , NULL ,0 , j ) ; 
end_method(MttsTaskDataX_CLASS , "setPriority" , setPriority , FULL , -1 , NULL , NULL , 0 , j ) ; 
end_method(MttsTaskDataX_CLASS , " setDependencies" , setDependencies , FULL , -1 , NULL , NULL , 0 , j ) 

end_method(MttsTaskDataX_CLASS , "getID" , getID , PURE , -1 , NULL , NULL , 0 , j ) ; 
end_method(MttsTaskDataX_CLASS ,"getPriority" ,getPriority , PURE , -1 , NULL , NULL , 0 , j ) ; 
end_method(MttsTaskDataX_CLASS ,"getDependencies" ,getDependencies , PURE , -1 , NULL , NULL , 0 , j ) 

create_alias(MttsTaskDataX_CLASS ,"MttsTaskDataX_CLASS",j) ; 


void Trans () { 

// This array is used to store the access permissions for parameters 
int ap_parametres [5] ; 

// This array is used to store the states of parameters 
int st_parametres [5] ; 

printf (" Trans it ions \n " ) ; 
for ( int j =0 ; j < = K ; j + + ) 

{ 

transitions_for_class_MttsTask (j ) ; 
transitions.f or_class_MttsTaskDataX (j) ; 

> 

> 


void Spec () { 

printf ( " Propert ies \n " ) ; 

//This checks the presence of deadlock. 
printf (" deadlock : ! EX ( true ) \n\n " ) ; 

//The next batch checks for every method being able to execute. 
for (int i =0 ; i < NUM.CLASSES ; i++) { 
for (int k=l ; k<= NUM_METHODS [i] ; k++){ 

printf (" reach_method_7,d_7,d : EF (method_°/ 0 d_0 = °/ 0 d /\\ pc_°/ 0 d_0 = °/ 0 d)\n", i, k, i, 
k, i, PRE); 

> 

//The adjacency matrix 
printf ( " \n\n " ) ; 

for (int k = 0 ; k< = NUM_STATES [i] ; k++) { 
for (int 1=1; 1 <=NUM_STATES [i] ; 1++) { 
if (k ! =1 ) { 

printf (" ad j acent _%d_%d_%d : state_ c / 0 d = %d /\\ EX ( st ate_°/ 0 d = °/ 0 d)\n", i, k, 1, i, 

k , i , 1) ; 

> 

> 

printf ( " \n " ) ; 

> 

> 

> 

int main (int argc , char *argv[]) 

{ 

K = 5; 

for (int i = 1; i < argc; ++i) { 

if ( strcmp ( argv [i] , "-k")==0 && i<argc-l) { 
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K = atoi ( argv [i + 1] ) ; 
if (K <0) { 

f pr intf ( stderr , " ERROR: invalid number of references, c /od.\n", K) ; 
f pr intf ( stderr , " need at least 1 reference An") ; 

return 2; 

> 

> 

> 


Init () ; 
Trans ( ) ; 
Spec () ; 
return 0; 

> 
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